Module based software system linking runtime to install time

ABSTRACT

A software product can comprise multiple components. At least one component comprising multiple feature sets. The feature sets can each define multiple OSGi bundles. The installation can include installing the OSGi bundles as indicated by the feature sets. The runtime can include loading the OSGi bundles as indicated by the feature sets.

CLAIM OF PRIORITY

This application claims priority to U.S. Provisional Application No.60/992,267 entitled “PATCH ATTACHMENT FACILITY” by David Felts, filedDec. 4, 2007, which is hereby incorporated by reference [Atty. DocketNo. BEAS-02252US0].

BACKGROUND

Installers are used to install software programs onto computer. In orderto use software programs, the program components are typically unpackedand the relevant information placed on the computer, taking account ofvariations between computers, and customized settings input by the user.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram showing the use of metadata so that an installer canautomatically install patches to a software product.

FIG. 2 is a diagram that shows an installer for a combined installationof multiple software products.

FIG. 3 is a diagram that shows the organization of the software productusing feature sets.

FIGS. 4A-4B illustrate product and feature metadata of one embodiment.

FIGS. 5A-5C illustrate product to component mapping, component tofeature mapping, and feature to module mapping of one exemplaryembodiment.

FIG. 6 illustrates an exemplary provisioning architecture.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In one embodiment, the patch management system 102 is used to loadpatches 104 onto software 106. One way to do this is to use a graphicaluser interface (GUI) 103 to select the patches to load. The patchmanagement system can keep track of the patches as well as thedependencies of the patches with the components of the software 106.Details of one embodiment of a patch management system are described inthe patent application entitled “PATCH MANAGEMENT SYSTEM”, by DavidFelts, filed Oct. 6, 2006, U.S. patent application Ser. No. 11/539,261[Attorney docket number BEAS-01780US1] incorporated herein by reference.

It is not always desirable for a user to be required to control theloading of the patches through GUI 103. In some cases, it is desirablethat the software be installed with the patches automatically loadedonto the system.

One embodiment of the present invention is a patch management system 102to load patches 104 to a software program 106. An installer 108 can beused to install components 109 of the software program 106. Theinstaller 102 can be adapted to interpret metadata 110 to instruct thepatch management system 102 to automatically load patches 104 to thesoftware program 106. The software components and patches can be loadedin a combined operation.

The installer 108 can use the metadata 110 to determine how to instructthe patch management system to load the patches. In one embodiment, thepatch management system 102 can receive the same set of controlinstructions from installer 108 as from the GUI 103. This can ensurethat there is no difference in the patch loading behavior whether it iscontrolled by the GUI 103 or installer 108.

The installer 108 and the patch management system 102 can update versioninformation based on loaded software components and patches. Forexample, one field of a version number can indicate any loaded patches.This can allow support operations to understand what is loaded on thesystem 105.

An install repository 120 can indicate what software components arestored on a system and be used to keep track of component dependence.The install registry can get information from a global product registry122 that can indicate all of the software component dependencies of anentire software product line. Dependencies can indicate what componentsneed to be loaded together as well as what components conflict. In oneembodiment, a patch catalog 124 is analogous to the global productregistry and indicates all of the patches as well as the patchesdependencies.

The metadata 110 can be used to determine the patches to place in aninstall package 128. The install package 128 can be used by theinstaller and the patch management system 102 to load the patches.

The metadata can be a XML file. The XML file can indicate what patchesto load in what order.

In one embodiment, the installer 108 checks the metadata 110 and theinstall registry 120 to determine what patches 126, and additionallywhat components 109, that need to be loaded. The components 109 can beloaded by the installer and the installer 108 can instruct the patchmanagement system 102 to load the patches.

In the example of FIG. 2, the installer 202 uses the install package 210to load the multiple software products 204, 206 and 208 onto system 212.The install package can include alias information indicating themultiple software products. The installer can determine from the aliasinformation that a combined installation is to be done.

The installer 202 can check an install registry 214 before doing theinstallation. The install registry 214 can indicate what is installed onsystem 212. The installer 202 can determine how to install the multiplesoftware products using the install registry 214. For example, theinstaller can check for and deal with any dependencies in the softwareproduct to be loaded.

In one example, if a software product is already installed on system212, the installer can skip installing that software product in thecombined installation.

It is desirable to have an installer 202 that can install multiplesoftware products in a combined operation.

In one embodiment, installer 202 does a combined installation ofmultiple software products 204, 206 and 208. The installer 202 can do acombined pre-install phase, a combined install phase, and a combinedpost-install phase for the multiple software products 204, 206 and 208.

The combined pre-install phase can be a phase in which the user inputfor the multiple products can be obtained. For example, configurationinformation for the multiple software products can be obtained from theuser at a single time.

The post-install can include the display of an indication of how theinstall went. For example, the post-install can be a display that thecombined install was successful.

In one embodiment, the multiple products can be hidden behind an aliasthat is used for marketing. The user need not even be aware of theidentity of the different software products.

In one embodiment, metadata identifying the multiple software productscan be provided to the installer. This can be alias metadata that pointsto the multiple software products.

In one embodiment, the loading of the software products can include theautomatic loading of patches using the system shown in FIG. 1.

The software products can each be made of components. The multiplesoftware products can be combined using an alias.

A software product 312 can comprise multiple components 314 and 316. Atleast one component 314 can comprise multiple feature sets 302 and 304.The feature sets can each define multiple OSGi bundles. The installationcan include installing the OSGi bundles as indicated by the featuresets. The runtime can also include loading the OSGi bundles as indicatedby the feature sets.

An installer can install the OSGi bundles as indicated by the featuresets.

Multiple products 320 and 312 can form a composite product 322. Thecomposite product 322 can be defined by an alias 324.

The software product 312 can be patched by switching OSGi bundles. Forexample, each bundle affected by a patch can be replaced by a newbundle.

An installer can use an alias 324 to indicate a combined softwareprogram 322. The combined program 322 can include multiple softwareproducts 320 and 312, the software products 320 and 312, each beingindependently runnable. The alias 324 can be used by the installersystem to install the multiple software products automatically.

The software product 312 comprises components 314 and 316. Thecomponents 312 and 314 can include feature sets 302 and 304. The featuresets 302 and 304 can include modules, such as OSGi bundles 306, 308 and310.

Exemplary Non-Limiting Embodiment

An exemplary non-limiting example showing one system using concepts ofthe present invention is described below.

A “Global Product Registry” (GPR) model can define company-wideproducts, product versions, components and maintenance levels, alongwith related attributes governing dependencies and distribution aspects.A File Definition model can contain the blueprint for file and directoryinstallation, mapping each file in the installer payload to its finaldestination on the customer's system. Many attributes, including rulesand filters, can govern the mechanics of file installation. An XML filecan embody the File Definition model and a separate file can exist foreach product. The File Definition model can be an important part of theextended Product Provisioning Model. The File Definition model iscritical to a change required to support shared modules.

Software companies have a growing need for greater business agility toopportunistically create bundled software distribution packages that mapto Stock Keeping Units (SKU's) consisting of new permutations ofavailable products.

Marketing and executive management require the ability to createarbitrary external product brand names and versions, while standardproduct provisioning operations require normalized internal productnames and versions. Structured product provisioning data can preservethe ability to upgrade and patch products consistently, enable customerprovisioning automation, and maintain reasonable supportability of theproducts.

Software companys' current architectural directions dictate modularityand modular product distributions. Product distributions can now containmodules, also known as bundles in OSGi parlance. Modules are verygranular. Consequently modules can require (1) a higher level intuitivesemantic for purpose of dependency declaration between function modulegroups as well as (2) a simplified method of starting OSGi-based runtimeapplications.

The Core Engine Launcher can require an interface to return module listsbased on requests for published feature versions. The interface canresolve dependencies and order modules appropriately by start level. Themodel used by the interface can be consistent with that used byinstallation to ensure that runtime dependencies are backed by installedmedia.

FIG. 4A shows a diagram of the metadata associated with a product of oneembodiment. Product Alias need not be part of the hierarchical producttree. A product alias can refer to one or more products, but this neednot imply parentage. In one embodiment, the official root of thehierarchical product model begins with a product element.

FIG. 4B shows a diagram that shows the relation of Feature Sets andModules. The Feature Model can be joined to components in the ProductModel via feature-refs (feature references). Think of components asbeing composed of features, rather than dependent on them, i.e. featuresdepend on features, but do not depend on any entity in the productmodel. This provides loose coupling between the Product Model andFeature Model, mapping runtime and install elements.

Provisioning code can depend on a product registry file. The productregistry file can be located in a Home folder. The registry can containinformation about products and the environment upon which productsdepend, e.g. specification of necessary virtual machines. Many valuesand related semantics can correspond to values in the GPR however theregistry is based on a separate model. This can be reflected inprocessing prevalent throughout the install framework. One embodiment ofthe new design calls for convergence of the GPR and registry models,adding critical information to the Home registry and simplifyingprocessing algorithms in the install framework. This can address a longstanding business requirement to enforce cross-product dependenciesduring un-installation. Further, this can facilitate an interface tocreate a list of modules along with normalized start levels based onactivation requests for products, components or specific features.References to the GPR in this document are synonymous with references tothe Product Model.

A Product Alias element can be added to the Product Provisioning Model,referencing one or more products. This can provide a loose couplingbetween the external market-oriented product name and version and theinternal product names and versions. The internal product names andversions can be captured in the registry and used for all code-baseddecisions during installation and other provisioning related activities.

A concrete Feature Model can be added to the Product Provisioning Model.A feature can be referenced by components in the Product Model andserves as a bridge linking install and runtime aspects of an artifact ormodule. Features can be versioned and contain a group of versionedmodules.

Modules can be grouped under features. Modules can be designated as“shared”. Shared modules need not belong to any specific product butrather can be targeted for distribution with two or more productsrequiring the same unit of functionality.

Product aliases can allow marketing flexibility without impact tonormalized, consistent methods of identifying software artifacts forpurpose of installation, un-installation, upgrade and patch. The productalias name and version may be unreliable for purpose of code and toolbased detection and automation, i.e. the versioning scheme may notfollow a rational, uniform syntax or be predictable with a consistent,monotonic, incrementing of the version number.

A product alias enables creation of a product suite from a group ofproducts. Moreover this layer of abstraction removes the need to modifyproduct names and versions with each new suite permutation. Thisfacilitates a consistent semantic for customer use, e.g. when contactingsupport or interfacing with a Patch Management system.

Product aliases can be defined in the GPR. The GPR can contain aseparate section for each product alias, which in turn containsreferences for each included product.

The term product defines the lowest level of granularity for a completesoftware offering targeted for customer consumption. Note that more thanone SKU may be defined for a given product based on product featuresenabled and usage characteristics of the features, e.g. constraintsplaced on features to restrict usage to a development scenario.

The product element can serve as a container for a group of components.In order to effectively deliver a product for customer consumption,components can be grouped and referred to by an immutable name andversion. This is done in order to develop and release product accordingto a standard lifecycle methodology. Orderly and automated installation,un-installation, upgrade and patching of products also uses a normalizednaming and versioning scheme. Moreover, this facilitates a consistentinterface for customers and effective customer support.

A product may contain a mixture of components used exclusively by thisproduct as well as components containing “shared modules” that can beused by multiple products.

Products can be defined in the GPR. The GPR can contain a separatesection for each version of a given product, includingservice/maintenance pack versions.

The components can define a functionally specific group of softwareexecutables and artifacts designed to provide customized productinstallation options. Installation options enable various customer usecases. A product can contain optional features that are appropriate onlyfor specific use cases. Providing the ability to optionally installenables a reduction in the footprint on disk and may reduce the downloadfootprint. Optional installation may also facilitate a developmentversus production product image. In the case of a productioninstallation, it may be necessary to avoid installation of certaincomponents whose presence represents a security vulnerability accordingto local policy.

Components can define dependencies on other components, includingcomponents belonging to different products. Multiple dependencies can beexpressed using a logical “and” or “or” semantic. Regular expressionscan also be supported.

Components can also contain feature references. Features in turn candefine dependencies, which are inherited by the parent component. Basedon dependencies, components may be automatically selected or de-selectedin installation and un-installation scenarios. Moreover, installationand un-installation errors or alerts can be generated when dependenciesspan products. Features are fully defined in the following section.Components can be defined in the GPR.

A feature can define a container element for modules as well asinter-feature dependencies. Features can be versioned as they arestandalone entities, not subject to any higher level element. Aparticular feature version can contain one to many module versions thatare functionally related and certified as compatible. Features can bethe primary entity used to identify modules to start in an OSGienvironment. Features can also be the primary vehicle used to distributecertified software combinations internally for consumers of the CoreEngine.

Feature Definitions can adhere to a schema-based model allowingdefinition of constituent modules and feature dependencies. Each moduleentry can contain a module name, optional start level and shared moduleindicator. When the Core Engine launcher processes module entries, themodule start level determines the sequence of module activation. Themodel also permits declaration of dependency elements capturingrelationships between feature versions.

Several files can support feature definition and dependencies. An XMLFeature Definition file embodies the Feature Model. A separate file canexist for each feature version. In one embodiment, it can adhere to thenaming convention <featurename>_(—)<4positionversion>.xml. A jar filecan be automatically generated during an installer build for eachfeature version. The jar file can consist solely of a manifest with aclasspath entry containing all modules listed in the Feature Definitionfile. Non-OSGi based runtime systems can use the jar files tosystematically create the appropriate classpath. The jar can adhere tothe naming convention <featurename>_(—)<4positionversion>.jar. Lastly,optional feature-set jars can hold manifest classpath references to acollection of related feature jars. A feature-set jar can adhere to thenaming convention <featurename>.feature.set_(—)<4positionversion>.jar.

Feature dependencies can define mandatory relationships between groupsof software executables and artifacts. Multiple dependencies can beexpressed using a logical “and” or “or” semantic. Regular expressionsneed not be required for features, as dependencies can be very direct.In one embodiment by contrast, regular expressions can be supported forthe component element, as both products and components are expressed independency relationships associated with components.

Logical “not” dependencies can enable handling of mutual exclusion usecases. A Feature Exclusion model can capture these exclusions. Separatemodeling of exclusions can avoid heuristics and performance problemsinherent with inclusion of this dependency type in the base dependencygraph. Exclusions can be processed after completion of base graphprocessing.

Feature dependencies can be independent of OSGI-based moduledependencies, which can be highly code dependent from a syntacticalperspective. Feature dependencies can relate to a logical dependency,e.g. one module writes a particular configuration file or entry in aconfiguration file that is required by another module. In this example,OSGI-based semantics may not capture the dependency.

A strong relationship can exist between runtime dependencies andinstallation artifacts and this can manifest itself in the relationshipbetween feature and component dependencies. Installation dependenciescan be a derivative of runtime requirements. The installer build processcan automatically percolate Feature Definition dependencies to relevantcomponent entries in the Product Model. Component dependencies can driveinstallation file processing.

Features can be defined in a separate model. Feature references can becoded under the component element in the GPR provide linkage between theProduct model and Feature Model. Components can be composed of features.

A module can be an OSGi-compliant file or other archive that can bedirectly loaded and used. For example, a module may be an OSGi bundle, ajar intended for use on the classpath of a Java-based runtime system ora WLS shared library. A module can contain an embedded version in itsfile name. Each module can provide very granular functionality.

A shared module can provide common functionality targeted for use by twoor more products. Shared modules can install under the Home directory,rather than a specific product directory. The installer can track usagefor each shared module via a reference count, since multiple productscan depend on the same module. Reference counting can prevent prematureun-installation of shared modules required by an active, installedproduct. A separate file can contain reference counts for all sharedmodules installed into a given Home directory. This file can resideeither under the Home directory or a well-known sub-directory of theHome directory. A separate file tracking all shared modules withassociated reference counts, rather than storing associated data in anexisting meta-data file can allow for efficient access. In theory,reference counts can be tracked in the Feature Definition file, but thiscan require traversal of all Feature Definition files duringun-installation processing.

The GPR can contain definitions for supported Java Virtual Machine (JVM)versions per product release. Each JVM entry can contain a definition ofsupported OS/architecture platforms.

The JVM definition can be a peer to component, rather than appearing asa component. There are several factors that drive this distinction. Aseparate versioning system can apply for the JVM and version upgradesand patches are not managed via the same mechanism as other productartifacts. Some products include multiple JDK's, including JDK'ssupplied by other vendors. Lastly, JDK/JRE installation can requiredifferent handling from a technical standpoint, where native compressionroutines are required to preserve symbolic links for some platform.Considering these factors, the JVM/JDK/JRE need not be consistent withother product artifacts and as such, a separate installation paradigmapplies.

Additional JVM/JDK/JRE information can be captured in a separate modeloutside of the GPR, embodied in a global XML file (jvm.xml). The modelcan include detailed version and vendor information, along withmeta-data used to construct the JVM from constituent parts, e.g. toolsversus the JVM library.

FIG. 5A shows an exemplary product to component mapping.

FIG. 5B shows an exemplary component to feature mapping.

FIG. 5C shows an exemplary feature to module modeling.

FIG. 6 shows an exemplary Product Provisioning Architecture. Theimplementation of the Global Product Registry (GPR) and Home RegistryFile include:

-   -   Create a new registry.    -   Provide synchronization routines to preserve old registry for        prior installers.    -   Modify internal data structures and API's throughout the        installation framework and public interfaces exposing related        metadata.        -   Include review of Maintenance Pack Installer to ensure            preservation of current conditional installation and            dependency enforcement processing, and appropriate handling            of shared modules.    -   Modify internal data structures and API's throughout the Patch        Management System framework. Review processing associated with        command line usage to ensure semantics are preserved.    -   Modify internal data structures and API's throughout the        Configuration Wizard framework, specifically concentrating on        component selection. A mapping to rationalize the current and        new Product Provisioning Models can be required.    -   Encrypt registry, providing accessors and mutators.        -   Business rationale: Filter sensitive data and protect from            manipulation and external dependencies.

Implementation of the Product Alias can:

-   -   Change installer displays to reflect the high-level alias for        customer consumption.    -   Change the installer component selection panel to display        product/component hierarchies rather than        component/sub-component hierarchies.    -   Change the installer product directory selection panel to allow        specification of multiple product directories. Allow for a        default product directory to apply across two or more products,        based on optional attributes in the GPR. Note that this can        require tight coordination across teams to ensure namespace        protection of artifacts not containing an embedded version in        the name of the associated directory or archives    -   Change product/component selection displays in Smart Update        (including SP/MP and Patch Management sections).    -   Change product/component selection displays in the CCE Patch        Management tool.

Feature and Dependency Processing can be implemented by:

-   -   Modify dependency graph and provide new graph traversal and        helper routines.

Shared Modules can be implemented by:

-   -   Provide reference counting.    -   Institute File Definition model changes and install build        routines.

Maintenance Pack Installer can be implemented by:

-   -   Review installer to ensure preservation of existing        functionality with the new Product Provisioning Model.

The Core Engine can specify the syntax and semantic for shared moduleversions (OSGi bundles). In one embodiment, the paraphrased versionsyntax can be defined as [major-release]. [minor-release].[maintenance-pack]. [sequential-patch-number].

The Patch Management System can provide support for multiple patchtypes/methods relevant to module patching. Business and technical usecases along with policy can drive selection of the most appropriatemethod. Complicating the picture, module usage by the Core Engine candiffer significantly from usage by WebLogic Server and dependentproducts. Increasing the complexity even further, WebLogic Server canalso support library modules, which have special requirements for namingand versioning as described in the Patch Management—Shared Archivesspecification.

The Patch Management System can generate a random and unique Patch IDfor each created patch. The random nature of the ID can support either a“one-off” or rolling patch model. Rolling patch semantics can becommunicated to the customer via the Patch Description field and furtherclarified by using UI characteristics of the Smart Update Tool thatdepicts Critical versus Optional patch groupings.

For shared modules consumed by the Core Engine, a complete replacementpatch type can be used. In one embodiment, the module name can change inthe fourth (patch) position of the embedded version string. Althoughclassified as a replacement patch type, from a file system perspective,this can involve installing a new module. This patch method can hold thegreatest negative impact for patch repository footprint, customer systemfootprint, and any operation requiring transport of the patch orpatchsets containing multiple modules. Further it may require additionalmanual handling by the customer to load the new patch module for runtimeusage.

A second viable model for shared module patching involves replacementpatches via injection, also supported by the Patch Management system.This method addresses the footprint issue and provides support for a“one-off” model. However, this would preclude use of signed modules andit appears to force global uptake of patches by all products dependenton the target module. The latter point may be addressable via customprofiles.

The Patch Management System can provide support for other patchinstallation patch types, e.g. classpath patching, path and libpathpatching, but these are not currently relevant to the module discussion.The diversity of patch types can provide flexibility for severaldifferent support models, e.g. one-off patches, full rolling patches androlling patches for a particular class of patches and are mentioned herefor completeness.

A Feature/Module Runtime Registry API can provide location independentaccess to product module registries and the means to start groups ofmodules using customer-friendly semantics. The initial consumer of theAPI can be the Core Engine Launcher, but the interface andimplementation can be generic, allowing potential use by any engine orserver predicating system start on modules.

The API can provide the following functions:

-   -   Returns launcher object        -   Artifacts constituting the launcher use the same feature and            version paradigm applicable to common modules, facilitating            a normalized interface.        -   The interface returns the highest version of the launcher    -   Returns module list        -   The module list contains module objects providing detail            about modules, e.g. location, based on the feature list            supplied in the request        -   Specific feature versions are not required as the API            detects multiple versions of a specific feature, returning            an exception in this case.        -   The list is ordered based on normalized start level.    -   Returns install directories associated with started products    -   Returns artifacts available for certain data categories, e.g.        configuration data, for started products        -   Artifact categories are associated with specific locations            in product directories. Categories and associated locations            are loosely coupled via a property file in a well-known            location relative to a product directory. Product teams can            manipulate the properties file, providing configuration            flexibility.    -   Returns Home directory

The API can provide a factory method returning a configuration object.The configuration object can provide a method that returns a module listbased on supplied parameters including product, component and features.The high level parameters, e.g. features, used in the interface insulatecustomers and internal developers from having to understand and specifythe full set of modules upon which they are dependent. Product teamswith intimate knowledge of their modules can group these together underintuitive features. As described earlier, components can be composed of,i.e. map features. Components in turn belong to products in the ProductProvisioning Model hierarchy.

The API can normalize module start levels across products. Module startlevels can be defined by each development team can be relative within aproduct. Creation of static module lists with start levels normalizedacross all product permutations can be extremely complex, error proneand require constant maintenance. Instead, this API can use a featuredependency graph to create a global module start order spanningproducts.

The archive can contain implementation classes for the API on theprimordial classpath, i.e. the same classpath used to start themicrokernel and launcher. This allows bootstrap of the launcher andensures knowledge of the Home directory location. The Home directory canbe the root of all critical bootstrap meta-data.

The feature dependency graph used by this exemplary API can support“and” and supports “or”, but need not support “not”. Enforcement ofmutual exclusivity can be achieved by a separate exclusion map, i.e. theFeature Exclusion Model. This can be applied after graph operations andnever changes the graph; heuristic conditions can be surfaced asexceptions. In one example, only a single version of a given feature isallowed in a list of features to start.

Software can incorporate a modular approach to developing anddistributing software. Modules can be shared by multiple products.Further, the paradigm for loading modules into runtime containersdiffers between the software products.

Software customers can be familiar with a style of patching referred toas “classpath” patching. Classpath patching enables very granularpatching of artifacts with a corresponding small download footprint.

The Core Engine can be based on a framework for managing applicationsspecified by an open standards organization known as the Open ServicesGateway initiative (OSGi). This framework need not support deterministicloading of duplicate classes spread across multiple jars/modules.Consequently, in one embodiment, Core Engine patches are delivered via acomplete module. The usability for consumption of patches in a CoreEngine environment can approximate that for other products and patchtypes, with reasonable latitude provided for intrinsic technicalcharacteristics of OSGi-based module launching.

The patch creation process can integrate intuitively with the existingtools and systems. Module patching need not require duplication ofeffort to accommodate the two runtime methods described above.

A “module” patch type can be used in the Patch Management System toaccommodate patching of entities referred to as modules or bundles.

The source artifact for inclusion in the patch can be a module ormodules. Modules can be selected from the file system via a file systemtree view in a similar fashion to selection of archives for patches ofthe type “classpath”. The selected archives can be then targeted tomodule entries. Each module entry can consist of a module name with anembedded version in the name. Targeting can involve a user interfacethat enables association of the source archive with a target modulename.

In one embodiment, when creating a module patch, two options can bepresented to the software design engineer for selection in the userinterface. In one example, at least one of the options must be selectedand both can be selected. The options are:

-   -   “Load via classpath”    -   “Load via OSGi”

Similar to classpath patches, only changed artifacts need be included inthe patch archives All other aspects of patch creation align withprocessing for other existing patch types.

The patch payload for module patches can closely mirror that ofclasspath patches. Installation of module patches for classpath loadingcan be similarly indistinguishable from pure classpath patches. However,a module patch can differ in its ability to create a patch forconsumption by an OSGi launcher.

Artifacts can be included in the patch classpath using the existingpatch management system mechanism applicable for classpath-basedpatching. This can provide continuity in processing for existingcustomers.

OSGi does not have the ability to deterministically load the same classfrom multiple jars/modules. Instead, a complete module containingpatched classes can be provided. The following steps can create acomplete module on the target system using essentially the same patchpayload created for classpath patches.

-   1. Duplicate the target module residing on the customer's system,    placing this in the default patch profile, or patch profile    explicitly selected by the customer. Note that the process of    duplication does not result in a file name change. This ensures that    no module references require modification. The use of patch profiles    and Patch Management System tracking functions can eliminate the    need to modify module name or embedded version.-   2. Inject artifacts (classes) from the downloaded patch payload into    the duplicated module.-   3. Track artifacts injected into the patched module by populating    entries in the patch backup definition file. This file is located in    the patch directory specific to the product/release/maintenance pack    level targeted by the patch. Track the sequence of patches applied    to the module. The logic supporting sequence tracking must handle    the use case where a customer performs un-install of a patch that is    not the latest patch applied. For example, given 5 patches applied    to a specific module, the customer performs un-install on the second    of the 5 patches applied from a chronological perspective. Note that    this approach doesn't require physical backup of the artifacts in    the patched module, as the injected artifacts still reside in the    patch directory. The control information residing in the patch    backup definition file together with the ability to re-inject    patches into the module supports all known un-install scenarios.-   4. Update the patch module list under the “patch” sub-directory of    the common modules directory located in the Home directory. This    module list contains entries for each patched module and identifies    the product/release/maintenance pack association for the module,    along with the patch profile under which the module resides.

Module patches can be applied to custom profiles, consistent with otherpatch types.

Runtime processing of module patches can differ depending on the systemused to load modules. Similar to patch installation, runtime processingof module patches loaded via the classpath can mirror processing oftypical classpath patches. The customer should not perceive a differenceunless they closely inspect internal meta-data.

Modules delivered via the Patch Management System and loaded using theclasspath function identically to classpath jars delivered under thecurrent version of the Patch Management System. Custom profile handlingand processing can be similarly consistent.

Different processing applies to modules delivered via the PatchManagement System and loaded by the Core Engine OSGi-based Launcher. TheLauncher can derive a list of modules to start by processing featurerequests using a Feature Registry API. This is the Launcher module startlist. For context, feature sets (also referred to as features) areversioned sets of functionally related modules that can expressdependencies on other features. Features can also have productaffinities.

After compiling a list of modules and prior to returning this to theLauncher, the Feature Registry API can compare the patch module list,created during patch installation, to the Launcher module start list. Ifa module matches on version and product association, the entry from thepatch module list can replace the corresponding entry in the Launchermodule start list. Note that the module version is embedded in themodule jar file name. The file object representing the patched modulecan be created using information from the module start list. Patchdirectories reside under the Home directory and are qualified byproduct/release/maintenance pack.

To accommodate use of custom patch profiles, the Launcher can add a newoptional flag to allow the customer to select a custom patch profile.Concurrently, the Feature Registry API can provide the ability tooptionally specify a custom patch profile applicable to module requests.In one embodiment, when handling requests involving custom patchprofiles, two differences apply to the processing described above.

-   -   Only entries identified as belonging to the specified patch        profile are selected for processing.    -   The file object representing the patched module is created using        a path that includes the custom patch profile directory tree.

Module patch un-installation can require additional handling to reverseprocessing and related meta-data specific to OSGi runtime requirementsas compared to a pure classpath patch.

Artifacts can be removed from the patch classpath using the existingPatch Management System mechanism applicable for classpath-basedpatching.

The following steps can change the state of the target system to removeany artifacts or meta-data relating to the patch being un-installed.Note that the state need not be restored to that of the system prior tothe original patch install, as other patches may have been installedduring the interim between patch install and un-install. Standard patchdependency checking can apply prior to initiating patch un-installation.

In one embodiment:

-   -   1. When un-installing the only patch currently applicable to a        given module, remove the patched module from the system.    -   2. If multiple patches are associated with a given module,        determine if the patch being un-installed is the latest patch        applied to the module. If it is the latest patch, re-inject        artifacts from the immediately prior patch.    -   3. Modify the patch backup definition file to show an updated        sequence of patches applied to the target module. If        un-installing a patch that is not the latest patch applied to        the module, do not modify the patched module. Remove meta-data        in the patch backup definition file that relates to this patch        in the sequence of patches applied to the module.    -   4. Remove the corresponding entry in the patch module list under        the “patch” sub-directory of the common modules directory        located in the BEA Home.

For support and debugging purposes, we can provide the ability to view asnapshot of all artifacts patched in a given module. Informationincludes the artifact name and associated patch identifier. The PatchManagement System's command line utility can invoke this function.

A patch attachment facility can:

-   -   Provide a mechanism to add patch installation as a loosely        coupled yet cohesive part of standard installation.    -   Provide an ability to easily configure this option as part of        routine meta-data modifications to install projects.

Build Activation can:

-   -   Provide ability to enable patch attachment facility via        build/project file switch.    -   The XML file embodying the installer patch model can be located        in a well-known location in the install build directory        structure.    -   The installer patch model's XML file can be referenced from a        build/project file variable.

Patch install model and usage can:

-   -   Provide ability to specify patches with component relationships        via schema-based model exposed in XML. For purpose of this        document, we'll refer to the model as the installer patch model.

Conceptually, patch installation can be filtered at two levels,execution level and individual patch level.

-   -   Execution Level—this level simply determines if a set of patches        should be evaluated for installation.        -   The list of patches can be scoped at a component level.        -   Multiple components and associated patch lists can be            included as part of the single installer patch model            instance.        -   Patches listed under a given component are evaluated if the            component is already installed on the system or has been            selected during the current installation session.    -   Individual Patch Level—this level can assume completion of the        Execution Level check and that the check indicates to evaluate        individual patch entries for installation        -   Each patch entry can identify the patch ID.        -   When the installer is built, the patch ID can be used to            query the Patch Catalog to extract the product to which the            patch applies. Patch meta-data is updated to make this            information available to the installer at runtime.        -   The Patch Management System need not associate patches with            installed components, thus we can check against product when            determining if it is appropriate to install a patch, i.e.            whether the patch application is meaningful given installed            products on the system. An alternative to this paradigm is            to require a dependent component semantic in the install            patch model. Weighing likelihood and ramifications of            installing a patch that is effective only for an optional            component that is not installed on the target system,            although the parent product is installed, versus a            requirement to manually identify dependencies in the install            patch model, the better design choice appears to be            automatic detection of product rather than checking            component and requiring that this be included in the patch            install model        -   Ideally, the patch ID can be used to query the Patch            Management System to determine if the patch is already            installed. However, this information is required relatively            early in the installation process, possibly before the Patch            Management System has been installed on the system. To            determine if the patch has already been installed, the            installer should first check if the product to which the            patch applies has been installed; if not, assume the patch            has not been installed. Otherwise, the product uninstall            definition can be inspected to determine if the patch was            installed via the installer invoked patch process. If the            patch is found in the uninstall definition, the definition            is updated to reflect newly installed components that            require the patch. If the patch was not found in the            uninstall definition, assume it is not installed. Note that            this might select patches that have already been installed            manually by the administrator, a situation that will be            detected later. If the patch is installed but not via the            installer invoked patch process, the patch entry can be            bypassed, i.e. not processed for patch installation.        -   The patch ID can be used to query the patch Management            System to determine the product associated with this patch.        -   The Patch Management System need not associate patches with            installed components, thus we can check against product when            determining if it is appropriate to install a patch, i.e.            whether the patch application is meaningful given installed            products on the system. An alternative to this paradigm is            to require a dependent component semantic in the install            patch model. Weighing likelihood and ramifications of            installing a patch that is effective only for an optional            component that is not installed on the target system,            although the parent product is installed, versus a            requirement to manually identify dependencies in the install            patch model, the better design choice appears to be            automatic detection of product rather than checking            component and requiring that this be included in the patch            install model.        -   If the product that a patch applies to is already installed            on the system or has been selected during the current            installation session, the patch is selected for            installation.        -   Once the patch is successfully installed via the installer            invoked patch process, an uninstall definition can be            created, including:            -   Patch ID            -   Evaluation level component            -   Individual patch level product            -   If the patch has already been installed via the                installer invoked patch process, the uninstall                definition for the patch should be updated to reflect                another individual patch level component association.

The installer patch model can provide the ability to define the order inwhich each patch is applied relative to the full list of patches. Patchordering can be independent of component association.

Patch payloads can be packaged with the components that require them.They are copied to the patch cache directory via the normal file copytask.

Client libraries required for the patch attachment facility areinstalled with a common component and will be dynamically added to theinstaller class path by a task that runs after the file copy task.

Patch installation can be tracked as part of the standard progressmonitor and UI.

Only begin and end events need be tracked as expected duration islimited. If use cases determine otherwise, appropriate events can beidentified such that progress monitoring can reflect actual progressmore effectively.

Patch status analysis (whether patches should be applied) can be splitfrom the actual act of applying patches during installation. This allowsconditional inclusion of progress monitoring for this function. Dynamicmodification of the progress monitoring process can be accomplished viaseveral methods. The planned implementation method is unspecified atthis point and is a lower level implementation detail.

Patch installation can be seamless, i.e. outside of inclusion instandard install progress monitoring no other UT elements should beaffected.

Embodiments of the present invention can include computer-based methodsand systems which may be implemented using conventional general purposeor a specialized digital computer(s) or microprocessor(s), programmedaccording to the teachings of the present disclosure. Appropriatesoftware coding can readily be prepared by programmers based on theteachings of the present disclosure.

Embodiments of the present invention can include a computer readablemedium, such as computer readable storage medium. The computer readablestorage medium can have stored instructions which can be used to programa computer to perform any of the features present herein. The storagemedium can include, but is not limited to, any type of disk includingfloppy disks, optical discs, DVD, CD-ROMs, micro drive, andmagneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, flash memoryor any media or device suitable for storing instructions and/or data.The present invention can include software for controlling both thehardware of a computer, such as general purpose/specialized computer(s)or microprocessor(s), and for enabling them to interact with a humanuser or other mechanism utilizing the results of the present invention.Such software may include, but is not limited to, device drivers,operating systems, execution environments/containers, and userapplications.

Embodiments of the present invention can include providing code forimplementing processes of the present invention. The providing caninclude providing code to a user in any manner. For example, theproviding can include transmitting digital signals containing the codeto a user; providing the code on a physical media to a user; or anyother method of making the code available.

Embodiments of the present invention can include a computer-implementedmethod for transmitting the code which can be executed at a computer toperform any of the processes of embodiments of the present invention.The transmitting can include transfer through any portion of a network,such as the Internet; through wires, the atmosphere or space; or anyother type of transmission. The transmitting can include initiating atransmission of code; or causing the code to pass into any region orcountry from another region or country. A transmission to a user caninclude any transmission received by the user in any region or country,regardless of the location from which the transmission is sent.

Embodiments of the present invention can include a signal containingcode which can be executed at a computer to perform any of the processesof embodiments of the present invention. The signal can be transmittedthrough a network, such as the Internet; through wires, the atmosphereor space; or any other type of transmission. The entire signal need notbe in transit at the same time. The signal can extend in time over theperiod of its transfer. The signal is not to be considered as a snapshotof what is currently in transit.

The forgoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many modifications andvariations will be apparent to one of ordinary skill in the relevantarts. For example, steps preformed in the embodiments of the inventiondisclosed can be performed in alternate orders, certain steps can beomitted, and additional steps can be added. The embodiments were chosenand described in order to best explain the principles of the inventionand its practical application, thereby enabling others skilled in theart to understand the invention for various embodiments and with variousmodifications that are suited to the particular used contemplated. It isintended that the scope of the invention be defined by the claims andtheir equivalents.

1. A system comprising: a software product comprising multiplecomponents, at least one component comprising multiple feature sets, thefeature sets each defining multiple OSGi bundles, wherein theinstallation includes installing the OSGi bundles as indicated by thefeature sets and wherein the runtime includes loading the OSGi bundlesas indicated by the feature sets.
 2. The system of claim 1, furthercomprising an installer to install the OSGi bundles as indicated by thefeature sets.
 3. The system of claim 1, further comprising multipleproducts forming a composite product.
 4. The system of claim 3, whereinthe composite product is defined by an alias.
 5. The system of claim 1,wherein the software product is patched by switching OSGi bundles.
 6. Asystem comprising: a software product comprising multiple components, atleast one component comprising multiple feature sets, the feature setseach defining multiple modules, wherein the installation includesinstalling the modules as indicated by the feature sets and wherein theruntime includes loading the modules as indicated by the feature sets.7. The system of claim 6, wherein the modules are OSGi bundles.
 8. Thesystem of claim 6, further comprising an installer to install themodules as indicated by the feature sets.
 9. The system of claim 6,further comprising multiple products forming a composite product. 10.The system of claim 9, wherein the composite product is defined by analias.
 11. The system of claim 6, wherein the software product ispatched by switching module bundles.
 12. A computer readable storagemedium comprising: feature sets defining OSGi bundles the feature setsbeing used to install the OSGi bundles at install time and to load theOSGi bundles at runtime.
 13. The computer readable storage medium ofclaim 12, wherein a software product is comprised of components that arecomprised of the feature sets.
 14. The computer readable storage mediumof claim 12, further comprising an installer to install the OSGi bundlesas indicated by the feature sets.
 15. The computer readable storagemedium of claim 12, further comprising multiple products forming acomposite product.
 16. The computer readable storage medium of claim 15,wherein the composite product is defined by an alias.
 17. The computerreadable storage medium of claim 12, wherein the software product ispatched by switching OSGi bundles.
 18. A computer readable storagemedium comprising: feature sets defining modules, the feature sets beingused to install the modules at install time and to load the modules atrun time.
 19. The computer readable storage medium of claim 18, whereinthe modules are OSGi bundles.
 20. The computer readable storage mediumof claim 18, further comprising an installer to install the modules asindicated by the feature sets.
 21. The computer readable storage mediumof claim 18, further comprising multiple products forming a compositeproduct.
 22. The computer readable storage medium of claim 21, whereinthe composite product is defined by an alias.
 23. The computer readablestorage medium of claim 18, wherein the software product is patched byswitching module bundles.